Lad os komme til bunden af, hvad Konsistens, Tilgængelighed og Partition Tolerance faktisk betyder i produktionsdistribuerede systemer. Hej folk, jeg er tilbage. jeg har ikke skrevet i et stykke tid, jeg ved, jeg ved. Mellem arbejde, liv, og den sædvanlige "er nogen endda læse dette?" tvivl spiral, jeg lader denne blog indsamle støv. I stedet for sporadiske indlæg om tilfældige emner, forpligter jeg mig til at dykke dybtgående serier om grundlæggende begreber, som jeg gerne ville have forstået bedre tidligere i min karriere. Hvis du nogensinde har følt, at du "får" distribuerede systemer i teori, men kæmper for at anvende den viden i praksis, er denne serie for dig. Tak fordi du læser denne blog (eller bare læser den). Få den fulde 4-del serie direkte til din indbakke. 
 
 Dette er del 1 i en 4-del serie om CAP teorem og distribuerede systemer kompromisser. Dette er del 1 i en 4-del serie om CAP teorem og distribuerede systemer kompromisser. Hvis du har interviewet for mellem- eller ledende ingeniørroller inden for det sidste årti, er du sikker på at have fået stillet et systemdesignspørgsmål, der i sidste ende fører til en version af CAP-teoremet. Selvom det er teknisk korrekt, er tanken bag det grotesk overforenklet.At overforenkling kommer tilbage til at bide dig, når du debuggerer, hvorfor din distribuerede datalagring gik ned. Mit mål er at afmystificere, hvad CAP-teoremet fortæller os, og forklare, hvordan produktionssystemer kommer rundt om denne "pick two" krak. Hvad er CAP Theorem? Lad os vende tilbage til århundredets drejning, i 2000. , der derefter kørte Inktomi Corporation, stod på podium af ACMs PODC-symposium og gjorde en erklæring, der ville plage udviklere i årtier: et distribueret datalagring kan kun garantere højst to af tre af følgende: Konsistens, Tilgængelighed og Partition Tolerance. af Eric Brewer Et par år senere blev Brewer's teorem formaliseret til et bevis af Seth Gilbert og Nancy Lynch. teoremet, ideen bag det, alt er sandt. Nå, alle husker den "pick two" del af gætningen, men de næsten altid udelade den vigtigste sammenhæng: . you only have to pick two   a network partition Under Under Når netværket er sundt, kan du have alle tre. Teoremet giver vejledning kun, når tingene går galt - når du begynder at miste netværkspakker, eller switches mislykkes, eller når en gnaver tygger gennem en fiberlinje (dette er faktisk sket på Amazon). CAP: Konsistens, tilgængelighed og partitionstolerance defineret Lad os være super præcise om, hvad C, A og P faktisk er, og hvad de betyder, fordi de tilfældige definitioner mangler en smule nuance. Hvad er konsistens i CAP-teoremmet? (lineariserbarhed) Når CAP-teoremet taler om konsistens, taler det om den højeste form for konsistens. Hvis du kommer fra en database baggrund, har du hørt om svag og stærk konsistens. Atomisk konsistens er blot et skridt over stærk konsistens. Atomisk konsistens er også kendt som . Atomisk sammenhæng Linearisering Linearisering Linearisering er, når alle operationer udføres For eksempel, hvis operation A afsluttes før operation B begynder, så skal operation B logisk træde i kraft efter operation A. Atomisk Lad os bruge et eksempel fra den virkelige verden til at illustrere denne idé. Forestil dig, at du tjekker din bankkontobalance, og du ser $5000. Lad os sige, at du overfører $1000 ud af kontoen. $4000 (eller en fejl), men aldrig $5000 igen. Overførslen enten skete eller ikke. Garantierne Garantierne Underskrive nu Dette er stærkere end "alle knudepunkter ser til sidst de samme data" - dette kaldes og det Hvad er det, CAP-teoretikken taler om? a lot Eventuel sammenhæng is NOT Hvorfor er dette vigtigt? fordi der er en masse systemer, der giver svagere konsistensmodeller, såsom: monotone læsninger, læsning-dine-skrivninger og kausal konsistens, samtidig med at det er yderst nyttigt. CAP-teoremet begrænser ikke systemer ved hjælp af disse modeller, kun lineariserbarhed. Meget tilgængelig Hvad er tilgængelighed i CAP Theorem? CAP's definition af tilgængelighed er også meget præcis, det siger "hver anmodning til en ikke-fejlende node Få et svar.” må Bemærk, at dette ikke betyder noget af følgende: 
 
 
 
 Svaret skal være hurtigt. Svaret skal være korrekt. Det er de fleste node, der skal svare. For eksempel, hvis du har en klynge på 10 knuder, og 4 af disse knuder er partitioneret væk, disse 4 knuder svarer stadig på anmodninger, der skal betragtes som "tilgængelige" i CAP's definition af "tilgængelighed". must Her er et eksempel i den virkelige verden: Under en netværkspartition vil et MongoDB primær replika-sæt, der ikke kan nå alle de sekundære replikaer, "træde ned" og nægte at skrive helt. , selvom MongoDB-processen kører som forventet. unavailability Hvad er partitionstolerance? (og hvorfor du ikke kan undgå det) Det er her, “pick two” rammer stemmer. Partitionstolerance betyder, at dit system fortsætter med at fungere som annonceret, selv når netværket opdeler dine noder i grupper, der ikke kan kommunikere. Netværkspartitioner er en realitet i distribuerede systemer. Internettet, som vi er afhængige af dagligt, de datacentre, der betjener vores applikationer, har alle denne egenskab. Switches fejler, fibre bliver klippet, cloud-udbydere har tilgængelighedszoner, pakker bliver droppet, selv inden for et datacenter er der forbigående netværksproblemer. Virkeligheden er, Du vælger ikke mellem C, A og P. Du vælger virkelig mellem C og A, når P uundgåeligt opstår. partition tolerance is absolutely mandatory Den virkelige handel Okay, lad os se, hvad der sker, når netværket til sidst fejler. Før vi gør det, lad os omformulere CAP-teoremet og dets valg, da P (Partition Tolerance) er absolut obligatorisk: 
 
 
 Konsekvens: Afvise anmodninger, der kan returnere forældede data (ofrer tilgængelighed) Tilgængelighed: besvare alle forespørgsler, selvom dataene ikke er tilgængelige (ofrer konsistens) Endnu en gang skal du være opmærksom på forudsætningen: “ Netværket fejler”. Hvis netværket er i orden, kan vi have både konsistens og tilgængelighed. Når der ikke er nogen partition? Du kan have begge. Din banks mobile app viser dig nøjagtige, opdaterede saldi, mens du forbliver meget tilgængelig – fordi det meste af tiden fungerer netværket fint. Du tjekker din balance, overfører penge og ser det opdaterede beløb med det samme. Når Spørgsmålet, som CAP-teoremet tvinger dig til at adressere, er: What should your system do when the network eventually fails? Den grundlæggende kompromis: Under en partition beskytter CP-systemer dig mod at se forkerte data ved at blive utilgængelige. AP-systemer beskytter dig mod nedetid ved potentielt at betjene stable data. Hverken godt eller dårligt, det hele afhænger af hvad der er rigtigt for dit system. CP Systems: Valg af konsistens over tilgængelighed CP-systemer beslutter, at de under en netværkspartition vil afvise anmodninger i stedet for at risikere at returnere forældede data. Hvornår giver det mening? 
 
 
 Banker: Hvis en bruger foretager en transaktion, er det foretrukket at være nede for lidt eller risikere transaktionen forekommer to gange? Sandsynligvis den første, rigtigt? Vi absolut ikke ønsker at fortælle kunden, at transaktionen lykkedes, når det ikke har. Inventarstyring: Hvis vi ikke er sikre på, om en vare er på lager, er det bedre at gøre tjenesten utilgængelig eller tillade muligheden for oversalg? Lad os analysere en real-world system, Fra deres egen hjemmeside: "etcd er en stærkt konsistent, distribueret nøgleværdi-butik ... Det håndterer graciøst ledervalg under netværkspartitioner og kan tolerere maskinefejl, selv i ledernoden." etcd Kubernetes bruger etcd som backup for alle klyngekonfigurationer.Hvis du har brugt Kubernetes før, har du set En af grundene til dette er, at det ikke er muligt at nå ud til de fleste af sine knudepunkter. etcd ofrer tilgængelighed ( Løsninger til linearisering. kubectl kubectl AP-systemer: Valg af tilgængelighed over konsistens AP-systemer beslutter, at under en netværkspartition risikerer de at servicere stable data i stedet for at benægte anmodninger. Nogle systemer, hvor dette gælder: 
 
 
 Social Media Feeds: Brugere ville meget hellere bruge appen til at servicere gammelt / forældet indhold i stedet for at være helt utilgængeligt. Derudover er det virkelig vigtigt, hvis en bruger ikke ser en reaktion på deres indlæg i et par sekunder? Shopping Carts: Et meget berømt eksempel på dette er Amazons DynamoDB, som faktisk begyndte at løse deres shopping cart problem; det er en "altid på" oplevelse. Du kan altid tilføje til kurven. For et real-world AP-system behøver du ikke tænke meget hårdt, det reneste AP-system er intet andet end DNS selv. DNS, Domain Name System, er det perfekte eksempel på et AP-system, og vi bruger det hundredvis af gange om dagen uden engang at indse det. Når en DNS-post opdateres, spredes opdateringen ikke til alle DNS-servere rundt om i verden med det samme. Det vil altid give dig et svar, selv hvis det svar er ustabilt. Dette er præcis hvorfor DNS-opdateringer tager tid, og hvorfor nogle websteder synes utilgængelige for nogle få mennesker, når de går igennem opdateringer. however Next Up: De skjulte omkostninger ved at vælge konsistens I den næste del af denne serie vil vi dykke dybt ind i CP-systemer - databaser og tjenester, der prioriterer konsistens over tilgængelighed under netværksfejl. 
 
 
 
 Hvordan disse CP-systemer implementerer stærk konsistens. Omkostningerne ved koordinering. Når man vælger konsistens over tilgængelighed, giver det mening. "Vælg to" giver illusionen af at være fast i dit valg for hele systemets levetid, når virkeligheden faktisk er meget mere fleksibel. Underskriv for at få del 2 når den falder. Tak igen for at holde sig rundt.Hvis du nød dette indlæg, bedes du abonnere, da det giver mig tillid til at fortsætte. af Ali Referencerne 
 
 
 
 2000 Podc præsentation af Eric Brewer Brewer's Conjecture og muligheden for konsekvente, tilgængelige, partition-tolerante webtjenester af Nancy Lynch og Seth Gilbert etcd

This story contains new, firsthand information uncovered by the writer.

Subscribe to my Blog

Newsletter

Read My Stories

Denne lyd er produceret på historiens originalsprog!

CAP Theorem forklaret, del 1: Problemet med "Pick Two"

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet Hubstaff: HackerNoon Company of the Week

Meet Octopus Network: HackerNoon Company of the Week

Meet Google Cloud: HackerNoon Company of the Week

Meet Sentry: HackerNoon Company of the Week

Meet Hubstaff: HackerNoon Company of the Week

Meet Octopus Network: HackerNoon Company of the Week

Meet Google Cloud: HackerNoon Company of the Week

Meet Sentry: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps